There is significant interest in using Ethernet switches in carrier networks. Use of Ethernet switches in carrier networks has the advantages of interoperability (mappings between Ethernet and other frame/packet/cell data structures such as IP, Multiprotocol Label Switching (MPLS) and Internet Engineering Task Force (IETF) Pseudowires are well known) and economy (Ethernet switches are relatively inexpensive compared to IP routers, for example).
Two notable technologies which allow the use of Ethernet switches in carrier networks are Provider Backbone Bridges (PBB) and Provider Backbone Bridge Traffic Engineering (PBB-TE). Provider Backbone Bridges (PBB), also known as Mac-in-Mac, is described in the Institute of Electrical and Electronics Engineers (IEEE) standard 802.1ah. PBB is a technology which allows for layering of the Ethernet network into customer and provider domains with complete isolation between their MAC addresses. In this way, a customer's traffic can be carried transparently across a carrier's Ethernet network. Nortel has proposed a form of ‘Connection-oriented Ethernet’ (CoE) which is described in International Patent Application WO 2005/099183 and in the paper “Ethernet as Carrier Transport Infrastructure”, David Allan, Nigel Bragg, Alan McGuire, Andy Reid, IEEE Communications Magazine February 2006. This technology is being standardized by the IEEE as IEEE 802.1Qay under the descriptor Provider Backbone Bridge Traffic Engineering (PBB-TE). In a PBB-TE network, the conventional Ethernet processes of ‘flooding’ and ‘learning’ are disabled and, instead, managed traffic paths are set up across the network of Ethernet switches. A network manager in the control plane instructs each Ethernet switch along a path to store forwarding information. The switch uses the forwarding information to forward received data frames. The forwarding information relates to a particular combination of identifiers in a data frame, the VLAN Identifier (VLAN ID or VID) and the destination MAC address (DA) in the case of Ethernet. As traffic is now constrained to follow pre-determined paths through the network, this allows network operators to perform traffic engineering on the Ethernet network, such as planning working and protection paths having diverse routes through the network and provisioning additional trunks to increase capacity. International Patent Application WO 2005/099183 describes moving packets between different planned PBB-TE paths, such as a working path and a protection path, by changing the VLAN ID in the header of the traffic packets.
Nortel has proposed a further Ethernet technology known as Provider Link State Bridging (PLSB) which is particularly suited to any-to-any services. In PLSB, the Intermediate System to Intermediate System (IS-IS) link state routing protocol is used to learn and distribute network topology information among Ethernet switches in a network, rather than using conventional Ethernet protocols such as spanning tree.
WO 2005/099183 describes the possibility of a mixed-mode network in which conventional Ethernet, bridged Ethernet (IEEE 802.1Q) and PBB-TE forwarding modes can co-exist simultaneously. The VLAN ID space is partitioned so that a first VLAN ID range (e.g. 1-2048) is assigned to conventional mode Ethernet forwarding and operates using VLAN-aware spanning tree protocol and auto address learning and another part of the address space (e.g. VLAN IDs 2049-4096) is assigned to PBB-TE. In this way, logically separate forwarding modes exist on the same physical network.
In a live network there is often a need to make changes to connections that have been set up for customers. It has been found that, in a mixed-mode network, there can be a need to migrate customers between connections which operate according to different types of forwarding mode, such as migrating from PBB to PBB-TE. This need can arise at short notice, and can require significant changes to be made to a live network to accommodate the needs of customers. It is desirable that any alterations made to a live network result in short or, ideally, no periods of outage. There is also a need to update functionality (e.g. by installing a new software release) at nodes of a live network with minimal disruption to customer traffic. Although software is tested before installation in a live network, it is not possible to test for every possible scenario and therefore it is not possible to guarantee what effects the new software release will have on live customer traffic.
The present invention seeks to provide an improved way of evolving a network which addresses at least one of the evolution scenarios outlined above.